• Tickets addressed: Hotfix
• Review: By commit
• Merge strategy: Merge (no squash)

Description

Resolves three bugs in our migrations:

1. In the AerieMerlin users migration, Aerie Legacy could accidentally get into the users table early. This would most likely occur as a side-effect of the tags migration using the username to indicate that a tag was from a version of Aerie prior to the tags table. This would cause a constraint violation when the migration went to assign allowed roles to all users added, and even if it didn't, there would be an on-insert conflict when the system users were properly added. This has been resolved by deleting the system users if they exist after all the insertions have occurred.
2. In the AerieScheduler definition_consistency migration, rows with a null definition field would violate the added not null constraint. This has been resolved by updating the rows with a null field to the default value for the row before setting the not null.
3. Migration 26 in AerieMerlin was missing a mark_migration_rolled_back call in the down.sql

Verification

Manual Verification in two ways:

1. I spun up a fresh Aerie, reverted migrations until I had reverted the two problem migrations. I then applied the bug situations (adding two tags, one whose owner was Aerie Legacy and another whose owner was Mission Model; adding a scheduling goal and scheduling constraint with null definition fields). I then migrated the database up to the latest version. All migrations were done using our Python DB migration helper.
2. Clipper had a deployment that was encountering these bugs. After running (1), these migrations were used to successfully migrate that DB from 1.7.0 to 1.12.0.

Documentation

No docs need to be updated.

Future work

Related to (3), I've created this issue